-
Notifications
You must be signed in to change notification settings - Fork 842
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implements #575 Better error handling via the new options 'error' and 'processSource' #640
base: main
Are you sure you want to change the base?
Conversation
When I check out this PR and run tests with mocha, I get 3 failing tests. |
I think it was done, but this PR is from some time ago, things may have changed in the mean time. I'd have to take a look at the failing tests. |
52f4ae4
to
74d689d
Compare
I checked out this branch and ran the tests, there was only 1 test failure; and that was because it was checking an error message that has changed in node 16 -- with node 14 all tests are passing for me.
Then I also rebased against the current main branch. Here the tests are also all passing.
I'm running on a Linux (Ubuntu) OS, perhaps there are some issues with the tests on Windows? |
One of the failing tests has test('supports error handler in client mode', function () {
assert.equal(ejs.render('<%= it.does.not.exist %>', {}, {
client: true, error: function(e){return e.toString();}
}), 'true&');
}); For me, that prints |
Closes #575 Better error handling via the new options
error
andprocessSource
From the readme:
Options
error
The error handler function used for the<%=
construct and<%-
construct. When an error is thrown within these constructs, the error handler iscalled. It receives two arguments:
err
(typeunknown
), which is the error objectthat was thrown; and
escapeFn
(type(text: string) => string
), which is the currentfunction for escaping literal text. The error function may return a
string
, and if itdoes, that value is inserted into the template instead.
processSource
Callback that is invoked with the generated source code of thetemplate, without the header and footer added by EJS. Can be used to transform the source.
The callback receives two arguments:
source
(string
), which is the generated source text;and
outputVar
(typestring
), which is the name of the variable that contains the templatetext and can be appended to. The callback must return a value of type
string
, which is thetransformed source. One use case for this callback is to wrap all individual top-level statements
in try-catch-blocks (e.g. by using a parser such as
acorn
and a stringifier such asastring
)for improved error resilience.
Error handling
In an ideal world, all templates are valid and all JavaScript code they contain
never throws an error. Unfortunately, this is not always the case in the real
world. By default, when any JavaScript code in a template throws an error, the
entire templates fails and not text is rendered. Sometimes you might want to
ignore errors and still render the rest of the template.
You can use the
error
option to handle errors within expressions (the<%=%>
and
<%-%>
tags). This is a callback that is invoked when an unhandled erroris thrown:
The code above logs the error to the console and renders the text
2 ERROR
.Note that this only applies to expression, not to other control blocks such
as
<%if (something.invalid) { %> ... <% } %>
. To handle errors in these cases,you e.g. can use the
processSource
option to wrap individual top-levelstatements in try-catch blocks. For example, by using
acorn
andastring
for processing JavaScript source code:
The above code logs the error to the console and renders the text
2 STATEMENT_ERROR
.